Transistors are electronic components that amplify a signal, or open or close a circuit. Joined together, transistors perform Boolean logic functions like AND, OR, NOT, NOR, and are called gates. Integrated circuits consist of transistors and the interconnections between them that perform specific functions. Integrated circuits, the interconnections, and transistors embedded in a semiconducting material are called semiconductor chips or chips. Integrated circuits and chips have become increasingly complex with the speed and capacity of chips doubling about every eighteen months. This increase is the result of, inter alia, advances in design software, and fabrication technology, semiconductor materials, etc. An increased density of transistors per square centimeter and faster clock speeds, however, make it increasingly difficult to design and manufacture a chip that performs as actually specified. Unanticipated and sometimes subtle interactions between the transistors and other electronic structures may adversely affect the performance of the circuit, which in turn increase the expense and risk of designing and fabricating chips, especially custom designed chips for a specific application. Yet, the demand for complex custom-designed chips increases with the variety of microprocessor-driven applications and products. Without an assured successful outcome within a specified time, fewer organizations are willing to attempt the design and manufacture of custom chips.
The challenge of designing complex integrated circuits has been met by introducing more powerful specialized software tools intended to design chips correctly and efficiently. As the software tools evolve, however, they become increasingly complicated, requiring more time to master and use them. Correspondingly, the cost of staffing, training, and coordinating personnel to perform the various aspects of chip design also increase. One general response to this dilemma has been a call for higher levels of abstraction, which simply means that the logical entities with which designers work are standardized and encapsulated like black box functions within the design. Although this abstraction has characterized the semiconductor industry throughout its history, the software tools used in chip design today are so complex that it is difficult to adapt them to this higher level of abstraction. There are several reasons for these difficulties, one of which is that the customers' different needs and specifications for integrated circuits must be aligned with standard and proprietary tools and capabilities of both designers and fabrication facilities.
To streamline a complicated process, any organization engaged in designing semiconductor chips first creates a methodology for doing so. Such a methodology comprises an ordered assembly of all of the tasks and tools required. For example, one part of the design methodology might specify tools and procedures to be used in designing the clocks, another for packaging, yet another for timing-closure, another for signal integrity and power for a chip with, e.g., over forty million transistors. The design methodology, moreover, must be updated frequently because technologies and requirements change, for instance, a new technology may require a different percentage of a different metal on a particular layer of the chip, so the methodology would be updated with a step to insert that metal layer in the specified areas of the chip. There are a myriad of other reasons to update the design methodology, such as to improve turn-around time, or to design a very large circuit.
The development of a methodology for the design of custom semiconductor chips requires the coordinated expertise of dozens of specialists whose work must be tracked and secured, integrated with the work of others, and tested. Until now, the design methodology has been essentially numerous documents having manual instructions for designing a chip to satisfy a customer's specification and the requirements for a technology and a fabrication facility. Each fabrication facility, it should be noted, operates with different design rules, equipment, molds, recipes and standards, all of which should be considered early in the process for best practices because they have implications for the final work product. The final methodology to design the chip, therefore, must match the tools that will be used to fabricate the chip, and be testable at various phases in the manufacturing process.
FIG. 1 represents the current state of the art for creating and/or updating a design methodology for designing a semiconductor chip. The process begins with a structured list of requirements for the new and/or updated design, called a specification 10. The specification 10 is divided into component problems and subproblems and sent to many, e.g., fifty, procedure or tool developers 20 working simultaneously and, most likely, isolated from one another. For example, one developer 22 may write procedures to specify how to design and test clock functions. The procedure for a clock function might, for example, call for a clock tool, request the chip designer to select various options, access files, and then execute the clock tool. Yet another developer may write procedures to create high-fan out nets; while other developers 24, 26, 28 write procedures to create input/output (I/O) rings; or place critical logic; reconnect scan chains; etc. Developers 20 are, moreover, continually testing these separate procedures; for example, a tool developer who writes code to insert a clock would test the code by running clocks at different frequencies, etc. The important aspect to remember, however, is that often these tool developers 20 are isolated from other tool developers 20, and thus while a tool may be internally consistent, once it is combined with the other tools, collectively, the tools may not yield correct results.
There are many problems inherent in this simultaneous development process. One problem, besides the isolation, is that typically tool developers do not know how the whole process is organized so that each developer is required to make many assumptions to complete her/his part of the design. More likely than not, these assumptions are not valid but won't be tested until later in the process. Another problem stems from the need for developers to use third-party commercial software with in-house or a customer's proprietary software tools. These tools are often written in different languages and frequently change because errors in the tools are found and fixed. In such a specialized and fast-changing environment, communication of errors and corrections is critical but difficult to actualize. Flawed tools and inconsistent versions of tools cause an erroneous design methodology but one whose flaws are not evident until later in the process.
Returning now to FIG. 1, all procedures written by the individual developers are typically stored, tracked, and secured until they are complete. When complete, at step 30, the procedures are combined by yet another isolated group of design architecture specialists into a methodology document 32 having hundreds of pages of descriptions of design procedures and sub-procedures.
The methodology document 32 is then sent for testing at step 40. Testing on the methodology document 32 is done manually, typically by several testers 42, 44, 46, 48, also isolated, using sample designs as testcases that make demands on the design methodology document 32. Initially, the testcases are simple ones that make modest demands on a design methodology document 32 but the testcases increase in complexity and speed through larger and more complete designs/testcases. Testers 42–48 are looking for the whole methodology document 32 to work so that all individual procedures culminate in a reliable design process. If the design methodology document 32 fails, as in step 50, notifications are sent to the developers 20, as in step 52, who then debug and correct the specification and/or individual tools. The correction is then recombined with the other development tools and the whole design methodology is tested again. Generally, what really happens is that one developer may fix her/his tool, only to cause another tool to fail testing. Distributing these dozens of files of the design methodology document 32, compiling test results, managing changes to the files and the methodology, the tools, etc. must be meticulously tracked. Right now, all this is done manually and is understandably prone to many mistakes, both human and resulting from the interactions of the many components of the design methodology contained within methodology document 32. In fact, more errors result from tools failing to interact properly with one another and because of the erroneous, albeit necessary, assumptions of the tool developers than from flaws in the logic of the methodology, yet both types of errors require debugging. Testing in this way is time consuming and awkward. Writing, combining, testing, rewriting, recombining, retesting, rewriting, recombining, retesting, without a doubt, is a tedious and expensive process.
The final design methodology document 60 consists of all the step-by-step processes involved in designing a specific chip. The design methodology document 60 may be more than 500 or even 1,000 pages in length. In a document of this complexity, it is difficult if not impossible to identify and resolve inadvertent inconsistencies and ambiguities that cause misinterpretations and errors. Such flaws are time-consuming and costly to test and rework. The design methodology document 60 may be released, as in step 70, to customers and designers 80 or to those who determine whether a customer's specifications for a semiconductor chip can be met. In either case, many people not involved in the development of the design methodology document 60 must read and understand it to design their chip. Because of the time pressures to design chips quickly and the tediousness of manually following these procedures, sections of the design methodology can be automated by scripting. Scripting, however, still requires considerable manual effort because it is a listing of procedures that are manually input.
There is thus a need in the industry for a method to automate and coordinate the development, the testing, and the release of the many tools required to create a flow methodology in the design of integrated circuits.